home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9611 / 000022_owner-urn-ietf _Mon Nov 4 12:05:57 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  3KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA05110 for urn-ietf-out; Mon, 4 Nov 1996 12:05:57 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA05104 for <urn-ietf@services.bunyip.com>; Mon, 4 Nov 1996 12:05:54 -0500
  3. Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA23564  (mail destined for urn-ietf@services.bunyip.com); Mon, 4 Nov 96 12:05:52 -0500
  5. Message-Id: <9611041705.AA23564@mocha.bunyip.com>
  6. Received: by privateer.windrose.omaha.ne.us; Mon Nov  4 11:04 CST 1996
  7. From: "Ryan Moats" <jayhawk@ds.internic.net>
  8. To: "Martin J Duerst" <mduerst@ifi.unizh.ch>
  9. Cc: "urn-ietf@bunyip.com" <urn-ietf@bunyip.com>
  10. Date: Mon, 04 Nov 96 11:06:14 
  11. Priority: Normal
  12. X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE
  13. Mime-Version: 1.0
  14. Content-Type: text/plain; charset="us-ascii"
  15. Content-Transfer-Encoding: 7bit
  16. Subject: Re: [URN] %encoding for reserved UTF-8 characters (was: New syntax
  17. Sender: owner-urn-ietf@services.bunyip.com
  18. Precedence: bulk
  19. Reply-To: "Ryan Moats" <jayhawk@ds.internic.net>
  20. Errors-To: owner-urn-ietf@bunyip.com
  21.  
  22. On Mon, 4 Nov 1996 17:37:06 +0100 (MET), Martin J Duerst wrote:
  23.  
  24. >Ryan Moats wrote:
  25. >
  26. >>>- Specify that protocols may only reserve 1-octet UTF-8 characters
  27. >>>    (i.e. ASCII).
  28. >>>- Specify that protocols have to define their own escaping mechanisms
  29. >>>    for things beyond ASCII.
  30. >>
  31. >>Having had the weekend to mull this over some more (and seeing that my
  32. >>mulling was in the right direction...), here are my thoughts:
  33. >>
  34. >>I would add a third solution to the above-- That the syntax draft defines its
  35. >>own escaping mechanism for things beyond ASCII.  This ensures that URN
  36. >>resolvers don't have to be re-written just because some new namespace comes
  37. >>along that wants to reserve some character in some totally different scheme
  38. >>then all the others currently used.
  39. >>
  40. >>Having said that, I currently lean strongly towards the first solution
  41. >>that Martin has
  42. >>proposed, as it keeps the syntax document short, doesn't add a new
  43. >>escaping mechanism (and all the complexity that adds).  To sum up, it just
  44. >>strikes me as being CLEANER than any other solution. Does anybody
  45. >>have problems with it being written into the syntax draft?
  46. >
  47. >It looks cleaner to me, too, maybe even a subset of ASCII, as Jon
  48. >Knight has suggested, because as I have explained, even now %7E
  49. >is used in some parts of the world to escape a "~" that is not
  50. >a reserved character.
  51.  
  52. I can live with a subset of ASCII, say from %20 to %7D.
  53.  
  54. >Also, I think we will never be able to fully exclude the second
  55. >solution, and we may even say in the draft that it is allowed,
  56. >but of course there will be no support from any generic handling
  57. >software.
  58.  
  59. I'd word it differently, but I can add such text as well.
  60.  
  61. Ryan
  62.  
  63.  
  64.